Method of controlling a network entity and a mobile station

ABSTRACT

A network entity and the mobile station are adapted to conduct a plurality of predetermined message exchange procedures, including encryption key generation procedures. The method comprises determining whether a received message from a mobile station is encrypted. If the received message is encrypted, it is determined whether a correct encryption key for decrypting said message is available to said network entity and, if no correct key is available, a predetermined triggering message is sent to the mobile station. The mobile station then interrupts the procedure exchange procedure and initiates an encryption key generation procedure.

FIELD OF THE INVENTION

The present invention relates to a method of controlling a networkentity of a mobile communication network and a mobile station arrangedto communicate with the mobile communication network, and to a networkentity and mobile station capable of performing the method.

BACKGROUND OF THE INVENTION

It is known to use encryption in mobile communication systems. In otherwords, in order to enhance security, messages exchanged over theair-interface between a mobile station and a network entity of a mobilecommunication network are encrypted, such that the sending side uses anencryption key and the receiving side requires an appropriate key fordecrypting the message and thereby discerning the message content. Itshould be noted that the present specification and claims shall use theterm “key” or “encryption key” with respect to keys used both forencryption and decryption. It should also be noted that the term“network entity” shall be used for any network element or combination ofnetwork elements that fulfils a given function, such as the function ofhandling message exchanges with a mobile station. As such, a networkentity can be provided by hardware, software or any combination ofhardware and software, and can be implemented in one node of a mobilecommunication network, or spread out over several nodes.

In order to provide both the mobile station and the network entity withappropriate corresponding encryption keys, with which each respectiveelement can decrypt messages received from the other, it is possible togenerate one encryption key in one element, store it in that element,and then transmit it to the other element. However, this is highlydisadvantageous, as it is possible that the encryption key sent over theair-interface is intercepted. Consequently it is preferred to implementrespective and corresponding encryption key generation procedures inboth the network entity and the mobile station, where correspondingencryption keys (which may be identical, or different from one another,depending on the encrypting scheme used) are respectively generated inparallel, such that the mobile station and the network entity can eachon their own have corresponding or matching encryption keys. Thecorrespondence between the encryption keys is ensured by usingcorresponding algorithms in the mobile station and network entity. Thisis well known and need not be described in more detail.

Furthermore, it is known to start the encryption key generation on thetwo respective sides using a common seed value, e.g. a regularly changedrandom or pseudo-random value broadcast by the mobile communicationnetwork to all network entities and listening mobile stations.

The generation of encryption keys is commonly performed at predeterminedinstances, for example when the mobile station registers with the mobilecommunication network. Usually the encryption keys are only generated atcertain types of registrations, such as power-on, the transition fromone switching entity (e.g. a mobile switching center MSC) to another, orforced registration, in which the network commands the mobile station toperform a registration.

The communication between a mobile station and a network entity iscommonly arranged such that it will use a plurality of message exchangeprocedures in the course of which predetermined messages are exchangedbetween the network entity and the mobile station, the type and numberof exchanged messages depending on the given message exchange procedure.Examples of message exchange procedures are a registration procedure, alink set-up procedure, a link configuration procedure, a call set-upprocedure etc. For example, if the mobile station wishes to originate acall, it will send a predetermined call origination request to thenetwork entity, and will then wait for a certain type of responsemessage. In other words, the mobile station will wait until a preciseand expected type of response from among a limited number of possibleresponses, e.g. one that confirms the receipt of the originationrequest, or one that provides call establishment information, etc.Messages not belonging to the limited group of expected responses willbe ignored and the entity will continue to wait for an expected message.Usually, a time-out feature will also be implemented, according to whichthe mobile station only waits for a predetermined time-out period. Afterthe time-out period expires, the mobile station can e.g. repeat therequest, or also enter an idle mode and indicate a corresponding failureto the user of the mobile station, e.g. a call establishment failure inthe above mentioned example of initially sending a call set-up request.

The message exchange procedures can be such that some or all exchangedmessages in a given procedure are encrypted. It may be noted that theterm “encrypted message” refers to any message of which at least a partis encrypted. For example, an encrypted message can be a message thatcontains a (first) unencrypted part and a (second) encrypted orencryptable part. As an example, a message could be contained in one ormore packets, each having a header and a payload section, where theheader is not-encrypted and the payload section is.

An example of rules governing the use of encryption in the communicationbetween a mobile station and the network entity of a mobilecommunication network is provided by standard TIA/EIA-136 published bythe Telecommunication Industry Association. In TIA/EIA-136 a mode calledenhanced privacy and encryption (EPE) is provided, which is anauthentication-related capability that adds confidentiality to signalstransmitted over a time division multiple access (TDMA) digital channelbetween a base station of a mobile communication network and a mobilestation. The encryption, if supported by the network entity and themobile station, is mandatory and is automatically activated, pendinghand shaking procedures between the mobile station and base station.TIA/EIA-136 specifies that with EPE encryption is automaticallyactivated after authentication is complete if both the mobile stationand the system support the feature. TIA/EIA-136 further specifies thatsupport for EPE is mandatory for mobile stations that adhere to protocolversion 4, but mobile stations that adhere to lower protocol versionsmay also support EPE.

The type of encryption applied together with the type of data encrypted,is controlled and authorized by means of encryption domains. Encryptiondomains define the level and type of encryption desired, the manner inwhich the encryption shall be applied and the data eligible forencryption. The encryption domain identifies portion of FACCH/SACCH(Fast Associated Control Channel/Slow Associated Control Channel)messages on digital or analogue channels that are subject to encryption,together with the encryption algorithm to be applied. Previously, forthe introduction of EPE, a single encryption domain had been defined,namely, Domain-A. This allowed the encryption of a portion of themessages on the FACCH/SACCH together with the payload (circuit-switchedspeech or data) on a digital traffic channel and a portion of themessages on the analogue voice channel. This information, defined by theDomain-A encryption domain, is eligible for encryption by the Domain-Aencryption algorithms only. The encryption of payload (circuit-switchedspeech or data) by a Domain-A encryption is commonly known as voiceprivacy or the encryption of layer 3 messages by a Domain-A encryptionis commonly known as Domain-A message encryption.

EPE introduces a new encryption domain, namely Domain-B. The Domain-Bencryption domain again defines a portion of the messages on theFACCH/SACCH digital traffic channel, a portion of messages on thedigital control channel together with payload (circuit-switched speechor data). This information, defined by the Domain-B encryption domain iseligible for encryption by Domain-B encryption algorithm.

A single encryption algorithm known as Scema is introduced as thedomain-B encryption algorithm, producing encryption keys for theencryption of both circuit-switched speech/data on a digital trafficchannel and Layer3 messages (both on digital traffic and digital controlchannels), as defined by TIA/EIA-136.

The Domain-B encryption applies to the following:

-   -   Domain-B message encryption for user signalling on the digital        control channel. The DCCH-encryption key (DCCH=Digital Control        Channel), generated in both the mobile station and the network        entity, is applied to specific Layer3 TIA/EIA-136 DCCH messages.    -   Domain-B message encryption for user signalling on the digital        traffic channel. The DTC-encryption key, generated in both the        mobile station and the network entity is applied to specific        Layer3 TIA/EIA-136 DTC-messages.    -   Domain-B encryption on the digital traffic channel for both        circuit-switched voice and data. The DTC-encryption key        generated in both the mobile station and the network entity is        applied to circuit-switched voice and data. EPE on the DCCH is        activated at registration. Both the mobile station and system        generate the Domain-B encryption keys, based on among other        information, the currently available value of a parameter called        RAND (a random variable which is broadcast on the control        channel) and other information. The generation of the keys is        performed on both the mobile station side and the network side        in parallel. This ensures that the encryption keys are        “synchronized”, where “synchronized” means that the keys on        either side are in correct correspondence to one another, such        that each side can decrypt the messages encrypted by the other        side. The generated encryption keys are stored in both the        mobile station and the network.

The encryption keys are only generated at certain types of registration,including power-on, transition to a new switching entity (MSC), andforced registration, where the network entity informs the mobile stationwhether EPE should be activated via the registration accept message.

Once activated, the mobile shall encrypt a portion of RACH messages(RACH=Random Access Channel) with the generated encryption key. Layer3messages subject to Domain-B encryption on the reverse digital controlchannel are: Origination, Page Response, R-data and Serial Number.

Layer3 messages subject to Domain-B encryption on the forward digitalcontrol channel are: Analogue Voice Channel Designation, Digital TrafficChannel Designation, Message Waiting-, Page, R-data, Registration Acceptand User Alert messages.

On reception of a message on the RACH from a mobile station camped on aDCCH, the network entity will determine whether a message is encryptedor not with Domain-B encryption, by using the message encryptionindicator field of the Layer2 extension header. If the message is notencrypted, then processing of the message will occur as implemented inthe given system. If the encryption indicator field indicates that amessage is encrypted with Domain-B encryption, the Domain-BDCCH-encryption key shall be retrieved from its storage location, e.g. avisitor location register VLR, where the encryption is stored togetherwith other information related to the subscriber using the mobilestation that is in communication with the network entity. Once theDomain-B DCCH-encryption key is available, the message shall bedecrypted and processing of the message is completed as implemented inthe network.

The terms Layer3 and Layer2 used above refer to different levelsspecified by TIA/EIA-136, and are not to be understood as layers withinthe meaning of the OSI model.

OBJECT OF THE INVENTION

The object of the invention is to improve the operation of a networkentity of a mobile communication network and a mobile station that areable to exchange encrypted messages, and which both are arranged toconduct respective encryption key generation procedures in parallel.

SUMMARY OF THE INVENTION

In accordance with the present invention, the network entity and mobilestation are arranged to operate such that if the network entity receivesa message from the mobile station, it determines whether the receivedmessage is encrypted, and if the received message is encrypted, itdetermines whether a correct encryption key for decrypting the messageis available to the network entity. In other words, it is determinedwhether any encryption key is available, and if one is available, it isdetermined whether this key is the correct one, which can be recognisedby analysing the decryption result. In other words, if the decryption isnot successful, then the used key is evidently not correct.

The network entity is furthermore arranged such that if no correct keyis available, then a predetermined triggering message is sent to themobile station. The mobile station is arranged such that upon receivingthe predetermined triggering message, it interrupts the message exchangeprocedure currently active, i.e. the procedure in the course of which itsent the encrypted message for which the network entity did not have acorrect key, and initiates an encryption key generation procedure.Through the parallel encryption key generation procedures, the mobilestation and network entity in parallel generate matching orcorresponding encryption keys and are thereby again “synchronized” withrespect to encryption, i.e. both have the correct encryption key fordecryption encrypted messages sent by the other side.

The specific advantage of the present invention lies in the fact thatthe mobile station does not wait until the ongoing message exchangeprocedure comes to an end by itself, e.g. by a time-out. Namely, it hasbeen recognised by the inventor of the present invention that underconventional circumstances, if for any reason the network entity can notobtain a correct encryption key for decrypting an encrypted messagereceived from the mobile station, the network entity can not respondappropriately, such that the mobile station will continue the ongoingmessage exchange procedure that sent the encrypted message, i.e. wouldwait for the expected response to the encrypted message, which expectedresponse, however, can not be provided by the network entity, as it cannot decrypt the message. During this time of continuing the ongoingmessage exchange procedure, i.e. waiting, a conventional mobile stationwill disregard any other communications or messages from the networkentity, even a message indicating that the mobile station shouldre-register. Such a re-registration will only occur when theconventional mobile station has returned to the idle mode after havingfinally abandoned the message exchange procedure. The time until theconventional mobile station abandons the message exchange procedure canlast very long, as it does not only include the time-out period, becauseit is also possible that after a first expiry of the time-out period,the mobile station will reinitiate the message exchange procedure usingencrypted messages, to which the network entity can not respond, suchthat several time-out periods may pass before the conventional mobilestation will enter an idle mode, in which it can re-register and therebyperform an encryption key generation procedure in parallel with thenetwork entity.

Such a disadvantage is completely obviated by the teaching of thepresent invention. Namely, if the network entity is unable to decrypt areceived encrypted message, it sends a triggering message to the mobilestation, whereupon the mobile station interrupts the ongoing messageexchange procedure, i.e. does not wait until a time-out occurs, in orderto immediately initiate an encryption key generation procedure inparallel with the network entity. Thereby, an unnecessary loss of timefor performing encryption key generation procedures in the networkentity and mobile station is avoided.

Preferably, the messages are arranged such that they have a first partand a second part, where the first part is an unencrypted part that isnot allowed to be encrypted (i.e. always unencrypted) and a second partthat is encryptable. Then, the unencrypted part may contain anencryption indication of whether the second part is encrypted or not,and the step of determining whether a received message is encrypted isperformed by analysing the encryption indication.

According to another preferred embodiment, when the messages arearranged such that the first part contains a message type identifieridentifying the type of the message (e.g. link set-up request, callset-up request, etc.), the network entity is arranged to identify themessage type of the received message from the message type identifier,and to determine whether the identified message type belongs to apredetermined category, and to only send the triggering message to themobile station if the message type falls into the predeterminedcategory. For example, the predetermined category can be that thereceived message is a set-up request. Then, the triggering message willonly be sent if the received encrypted message for which no correctencryption keys available, is a set-up message. According to anotherpreferred embodiment, the encryption key generation procedures used inthe network entity and the mobile station comprise obtaining anencryption base value, such as the seed value mentioned in theintroduction, for generating corresponding encryption keys basedthereon. Preferably, the encryption base value is a regularly changedvalue that is broadcast by the network to listening mobile stations,such as the above mentioned random or pseudo-random value RAND.

According to another preferred embodiment, the encryption key generationprocedure is conducted as a part of a registration procedure for themobile station with the network entity. In other words, the initiationof the encryption key generation procedure comprises initiating aregistration or re-registration procedure of the mobile station with themobile communication network to which the network entity belongs, in thecourse of which parallel encryption key generation procedures areconducted in the network entity and the mobile station.

BRIEF DESCRIPTION OF DRAWINGS

Further aspects and advantages of the present invention shall becomeapparent from the study of the following detailed description ofpreferred embodiments of the invention, which are given as examples andare not intended to be limiting, where the description makes referenceto the attached drawings in which:

FIG. 1 shows a schematic representation of a mobile station of anembodiment of the present invention;

FIG. 2 shows a flowchart of a procedure conducted in a network entity inaccordance with an embodiment of the present invention;

FIG. 3 shows a flowchart of a routine conducted in a mobile stationaccording to an embodiment of the present invention;

FIG. 4 shows a schematic representation of a mobile station and anetwork entity according to an embodiment of the present invention; and

FIG. 5 shows a schematic representation of a message containing a firstunencrypted part and a second encryptable part.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a schematic block diagram of a mobile station 1 arranged tooperate according to the present invention. FIG. 1 shows an antenna 11,a transmitting and receiving part 12, and a signal processing section13. The signal processing section 13 comprises a processor 132 and amemory 131. The processor 132 is indicated as comprising an encryptionkey generator 1321, a message encryptor/decryptor 1322 and a controller1323 for controlling the operation of the mobile station. It may benoted that the mobile station will generally contain furtherconventional features, such as a microphone, loudspeaker, display,keyboard and other well known elements, which are not shown, as theyhave no relevance for the present description.

The encryption key generator 1321, message encryptor/decryptor 1322 andcontroller 1323 are shown as being software components executed by theprocessor 132. However, it may be noted that they could also be providedas separate hardware components, or as any suitable combination ofhardware and software.

The encryption key memory 131 can be provided in any suitable ordesirable way, e.g. as a RAM. The signal processing section 13 cancomprise further memory elements, such as ROMs for storing software andother information, where such additional memory elements are not shownfor simplicity.

According to the embodiment shown in FIG. 1, the encryption keygenerator 1321 serves to generate an encryption key, which is thenstored in the encryption key memory 131. The message encryptor/decryptor1322 encrypts messages sent to the mobile communication network by themobile station 1, and decrypts messages received from the mobilecommunication network, by using one or more stored encryption keys. Thecontact with the mobile communication network is established by thetransceiver 12 and antenna 11, as is well known, such that a furtherdescription is not necessary here.

According to the embodiment of FIG. 1, the controller 1323 is arrangedto control the operation of the mobile station 1, and is specificallyarranged to perform one or more predetermined message exchangeprocedures with the mobile communication network, such as a link set-up,call set-up, etc. In the course of such message exchange procedures, themobile station sends predetermined types of messages (such as a callset-up request) and waits for predetermined corresponding types ofresponse messages from the communication network (such as a call set-upacknowledgement). Furthermore, the controller 1323 is arranged toidentify the receipt of a predetermined unencrypted triggering messagefrom the mobile communication network during the course of an ongoingmessage exchange procedure, and is arranged to interrupt the ongoingmessage exchange procedure in response to receiving the predeterminedunencrypted triggering message, and to then initiate an encryption keygeneration procedure.

This can also be seen in the flow chart of FIG. 3, which shows a part ofa routine executed by the controller 1323. In step S31, the receipt of anew message from the mobile communication network is detected.Subsequently, in step S32 it is determined whether the received messageis of a predetermined type and is a triggering message. If it is atriggering message, then the procedure goes to step S33, in which theongoing message exchange procedure is interrupted, and whereupon stepS34 is conducted, in order to initiate an encryption key generatorprocedure, e.g. as a part of a registration or re-registration procedureof the mobile station with the mobile communication network. On theother hand, if step S32 determines that the received is not thepredetermined triggering message, then the procedure branches to stepS35, in which the ongoing message exchange procedure is continued.

FIG. 4 shows a schematic representation of a network entity and a mobilestation 1. In the example of FIG. 4, the network entity consists of abase station part 4 and a traffic control part 5, where said basestation part 4 comprises a base transceiver station (BTS) 41 and a basestation controller (BSC) 42. The traffic control unit 5 comprises amobile switching network (MSC) 51 and a data base 52, which comprises ahome location register (HLR) and visitor location register (VLR). Thenetwork entity thereby has the structure known from GSM, such that afurther description is not necessary here. It may be noted that the basestation controller 42 may be connected to a plurality of basetransceiver stations, and that the mobile switching center 51 may beconnected to a plurality of base station parts (i.e. a plurality of basestation controllers). Also, the mobile switching center 51 is typicallyconnected to further network entities, such as gateways to othernetworks, which is well known in the art and not shown in FIG. 4 forsimplicity.

According to the embodiment of FIG. 4, the network entity provided bybase station part 4 and traffic control part 5 comprises an encryptionkey generator 511 located in the mobile switching center 51, where thedata base 52 acts as an encryption key memory for storing encryptionkeys generated by the encryption key generator 511. Furthermore, amessage encryptor/decryptor 421 is provided in the base stationcontroller 42 for encrypting messages sent to the mobile station 1 anddecrypting messages received from the mobile station 1 using anencryption key stored in the database 52. It may be noted that thegenerated encryption keys are preferably stored in the VLR part of thedatabase 52, in association with other data belonging to the subscriberusing the mobile station 1.

The mobile switching center acts as a controller for controlling thecommunication between the network entity 4, 5 and the mobile station 1,where the MSC 51 is arranged to determine whether messages received fromthe mobile station 1 are encrypted or not, and if a received message isencrypted, determining whether a correct key for decrypting the messageis available or not. If no correct key is available, then apredetermined unencrypted triggering message is sent to the mobilestation 1, for triggering an immediate encryption key generationprocedure in the mobile station 1, as explained previously with respectto FIGS. 1 and 3. An example of a routine executed by controller 51 isshown in the flow chart of FIG. 2. In step S21 it is determined whethera message received from the mobile station 1 is encrypted or not. StepS21 can be implemented in a variety of ways. For example, it is possiblethat the mobile station 1 sends un unencrypted indication signal to thenetwork entity, said unencrypted indication signal informing the networkentity that all subsequent messages sent by the mobile station areencrypted. In this case, step S21 simply consists in determining thatthe message is such a subsequent message. Preferably, the messagestructure is as shown in the example of FIG. 5, namely a message 6consists of a first part 61, which is not allowed to be encrypted, and asecond part 62, which is encryptable. The unencryptable part 61preferably contains a message type identifier 610 that identifies thetype of the message (e.g. as a call set-up request), and an encryptionindication 611 that indicates whether the encryptable part 62 is in factencrypted or not. As such, the encryption indication 611 can be a singlebit, where one bit value indicates encryption and the other lack ofencryption. Naturally, the encryption indication 611 can also be morecomplicated and contain further information.

In this case, step S21 in FIG. 2 consists in examining or analysing theencryption indication 611. If the message is encrypted, step S22determines whether a correct key is available. For example, this canconsist in determining whether any key is available in the database 52for the mobile station 1 (the subscriber using mobile station 1), and ifnot, then this already indicates that no correct key is available.However, it is also possible that a key is available, but that adecryption attempt for the received message leads to the conclusion thatthe key is not correct, as it does not lead to a successful decryption.

There are several reasons why a correct encryption key may not beavailable for decrypting the received message. For example, if theencryption keys are stored in the VLR in association with othersubscriber data, it is possible that they are deleted in the course ofregular “re-cycling” operations conducted by the operator of thenetworks, in which subscriber records are deleted if the correspondingmobile station has not registered with the network within anoperator-defined period of time. It is possible that an active mobilestation has disabled the periodic registration function, or that it has“missed” a registration due to temporary communication problems. If thesubscriber record has been re-cycled, then the encryption key is lost,and if the mobile station then proceeds to send an encrypted message,e.g. a call set-up request, then the network entity can not decrypt themessage and respond accordingly.

Returning to FIG. 2, if the outcome of step S22 indicates that nocorrect key is available, then a procedure S23 is initiated, in which apredetermined unencrypted triggering message is sent to the mobilestation, which makes the mobile station conduct an immediate encryptionkey generation procedure. In the course of this encryption keygeneration procedure, e.g. a registration or re-registration, thenetwork entity also performs an encryption key generation procedure inparallel, such that matching or corresponding encryption keys areavailable both in the mobile station and the network entity, andencrypted messages can again be exchanged without any problems.

In the example of FIG. 4, the message encryptor/decryptor 421 and theencryption key generator 511 are shown as software routines implementedin the base station controller 42 and mobile switching center,respectively. However, it may be noted that the encryption key generator511 and the message encryptor/decryptor 421 can also be provided asseparate hardware elements or as any suitable combination of hardwareand software. Moreover, the structure of the example of FIG. 4 is onlyan example, and the functional elements can also be provided otherwise,e.g. spread out over all of the shown nodes or provided in other nodes.Moreover, the database 52 associated with the mobile switching center 51can be used as an encryption key memory, but an encryption key memorycan also be provided in association with any other element shown in FIG.4. Furthermore, although the example of FIG. 4 is related to GSM, theconcept of the present invention is not restricted to GSM mobilecommunication networks, but can be used in the context of any mobilecommunication system in which encrypted messages are used, and in whichencryption key generation procedures are implemented on the mobilestation side and the network side.

Now a preferred embodiment of the present invention shall be explainedin the context of the standard TIA/EIA-136 discussed in the introductionto the application. It may be noted that the discussion of TIA/EIA-136in the introduction is herewith incorporated into the disclosure of theinvention.

On reception of an encrypted RACH message from the mobile station, thenetwork entity will be able to determine that the message is encryptedvia the Layer2 header information (as e.g. shown in FIG. 5). If theBomain-B DCCH-encryption key is not available and the network entity isunable to decrypt the message, it can use a message indicator (such asthe indication 610 shown in FIG. 5) to determine what message the mobilehas sent as the message type is not encrypted.

As one possibility, the network entity can reject the service requestedby the message, regardless of the message type, and send an unencryptedlayer 3 message to the mobile station, stating that the reason forrejection is a “system-related cryptography mismatch”. Preferably, themessage indicating the system-related cryptography mismatch is only sentfor messages of a certain type. In other words, it is preferablyanalysed whether the message type of an encrypted message that is notdecryptable belongs to a predetermined category (e.g. the categorydefined by all set-up messages), and the message indicatingsystem-related cryptography mismatch is only sent if the receivedencrypted message belongs to the predetermined category.

More specifically, examples of received encrypted messages from themobile station in response to which the network entity can send amessage indicating system-related cryptography mismatch are thefollowing Layer3 messages: Origination Message, Page Response Messageand R-data Message. In response to the Origination Message, the networkentity can build a Reorder/Intercept message including the indication“system-related cryptography mismatch” in the Cause ExtensionInformation Element. In response to the Page Response Message, thenetwork entity can send a Release message, which also includes the“system-related cryptography mismatch” in the Cause ExtensionInformation Element. Finally, in response to the R-data message, thenetwork entity can send a Reorder/Intercept message, also including the“system-related cryptography mismatch” in the Cause ExtensionInformation Element. Alternatively, a R-data reject message can also besent.

On reception of one of the above described response messages, which areall examples of triggering messages, the mobile station is arranged toexamine the received cause value (the Cause Extension InformationElement). If the reason is “system-related cryptography mismatch”, themobile station is arranged (programmed) to immediately interrupt theongoing procedure (e.g. interrupt waiting for the appropriate responseto the sent message), and declaring a Forced Registration condition, inorder to invoke a Registration procedure. In the Registration procedure,a parallel encryption key generation procedure is conducted in themobile station and the network entity. The registration procedure ise.g. specified in TIA/EIA-136-123: TDMA third generation wirelessdigital control channel Layer3.

In order to implement the above described example in context ofTIA/EIA-136, the appropriate specification may be updated as follows:The Cause Extension IE should be updated to contain the rejection reason“system-related cryptography mismatch”. The Waiting for Order Stateshould be updated to allow the mobile station to declare a ForcedRegistration condition and invoke the Registration procedure onreception of a Release message, specifying the reason for rejection as“system-related cryptography mismatch”. The Origination Proceeding Stateshould be updated to allow the mobile station to declare a ForcedRegistration condition and invoke the Registration procedure onreception of a Reorder/Intercept message specifying the reason forrejection as “system-related cryptography mismatch”. The OriginatedPoint-to-Point Teleservice Proceeding should be updated to allow themobile station to declare a Forced Registration condition and invoke theRegistration procedure on reception of a Reorder/Intercept message,specifying the reason for rejection as “system-related cryptographymismatch”.

1. A method of controlling a network entity of a mobile communicationnetwork and a mobile station, wherein said network entity and saidmobile station are adapted to conduct a plurality of predeterminedmessage exchange procedures in the course of which predeterminedmessages are exchanged between said network entity and said mobilestation depending on the given procedure, where said predeterminedmessages may be encrypted, an encrypted message being any message ofwhich at least a part is encrypted, and where said network entity andsaid mobile station are adapted to conduct one or more encryption keygeneration procedures during which the network entity and the mobilestation generate and store respective corresponding encryption keys inorder to be able to encrypt and decrypt exchanged messages, said methodcomprises the steps of: if said network entity receives a message fromsaid mobile station, determining whether said received message isencrypted; if the received message is encrypted, determining whether acorrect encryption key for decrypting said message is available to saidnetwork entity and, if no correct key is available, sending apredetermined triggering message to said mobile station; and uponreceiving said predetermined triggering message, said mobile stationinterrupting the procedure in the course of which it sent the encryptedmessage for which the network entity did not have a correct key, andinitiating an encryption key generation procedure; wherein said messagesare arranged such that they have a first part and a second part, saidfirst part being an unencrypted part that is not allowed to beencrypted, and said second part being encryptable; and, wherein saidmessages are arranged such that said first part contains a message typeidentifier identifying the type of the message, and after havingreceived a message from said mobile station, said network entityidentifies the message type of said received message from the messagetype identifier and determines whether said identified message typebelongs to a predetermined category, and sends said predeterminedtriggering message to said mobile station only if the message type ofsaid received message falls into said predetermined category.
 2. Themethod according to claim 1, wherein said messages are arranged suchthat said first part contains an encryption indication of whether saidsecond part is encrypted or not, and said determining of whether thesecond part of said received message is encrypted or not is achieved byanalysing said encryption indication.
 3. The method according to claim1, wherein said one or more encryption key generation procedurescomprise obtaining an encryption base value commonly available to saidnetwork entity and said mobile station at the time of conducting saidencryption key generation procedure, and generating correspondingencryption keys in said network entity and said mobile station on thebasis of said encryption base value.
 4. The method according to claim 3,wherein said encryption base value is a regularly changed value that isbroadcast by said network to listening mobile stations.
 5. The methodaccording to claim 1, wherein said encryption key generation procedureis conducted as a part of a registration procedure of said mobilestation with said network entity.